Быстрый старт
Программный комплекс Solar TI Feeds предназначен для периодической загрузки полного списка фидов, получения изменений с момента последнего запуска и получения изменений по нотификациям. Solar TI Feeds обеспечивает взаимодействие с различными источниками индикаторов компрометации информационных систем, поставляемых облаком TI Feeds, для формирования централизованной базы знаний об угрозах информационной безопасности и индикаторах компрометации информационных систем.
Solar TI Feeds API предоставляет доступ к актуальным фидам индикаторов компрометации через REST API-интерфейс.
API располагается по адресу api.data.rt-solar.ru
Термины и определения
Индикаторы компрометации (IOCs) — это конкретные признаки, по которым можно распознать потенциальную угрозу ИБ. Среди распространяемых данных от к ним относятся:
- IP-адреса, связанные с преступной активностью
- Домены, используемые злоумышленниками
- URL, используемые злоумышленниками
- Хеши вредоносных файлов
Индикатор атаки (IoA) — это правило, содержащее описание подозрительного поведения в системе, которое может являться признаком целевой атаки.
Категории индикаторов - базовая классификация индикаторов по типу угрозы. Категория — это классификационный признак, который определяет:
- Классы вредоносного программного обеспечения;
- Сущность конкретного индикатора;
- Основные свойства и характеристики объекта Примеры категорий: Ransomware, Phishing, Stealer, С2.
Фиды (Threat Intelligence Feeds) — это потоки данных, содержащие различные индикаторы угроз. Они представляют собой каналы получения информации об угрозах кибербезопасности. Фиды формируются из общего списка индикаторов на основе правил, определяющих принадлежность индикатора к тому или иному фиду по заданному набору признаков.
Фид — это агрегирующий признак, который:
- Служит для группировки индикаторов;
- Может быть связан как с характеристиками угрозы, так и с другими параметрами;
- Позволяет объединять индикаторы по различным признакам (не только по угрозам)
- Примеры фидов: Ransomware, Phishing, Fincert, 4RAYS Pulse.
Поле «Фиды» - список фидов, в которых содержится данный индикатор. Следует отличать поле «Фиды» от понятия Фид - логическая группировка индикаторов на основе их признаков. Индикатор может попасть в фид по некоторым условиям, например, по принадлежности к какой-либо категории или на основе источника, из которого индикатор был получен. Фид может формироваться по категории или источнику индикатора, но не для всех категорий и источников такое возможно. Поэтому визуально может показаться, что поля «Категория» и «Фид» дублируют друг друга, но это не так, скорее поле фидов может в себя включать часть множества поля категорий. Таким образом, хотя категории и фиды могут пересекаться по содержанию, они выполняют разные функции в Solar TI Feeds и предоставляют различные уровни классификации и использования индикаторов.
Ключевое отличие между категорией и фидом заключается в следующем:
- Категория всегда характеризует саму сущность индикатора, определяет природу и характеристики угроз
- Фид помогает организовать индикаторы в группы по различным критериям и может быть связан как с характеристиками индикатора, так и с внешними признаками группировки, например, источником получения индикаторов.
Типы индикаторов компрометации (IoC)
В данном разделе приведено описание форматов индикаторов, поддерживаемых платформой Solar TI Feeds.
| Тип | Формат (рус.) | Определение | Пример |
|---|---|---|---|
| IPV4 | IPv4 адрес | 32-битный IP-адрес сетевого уровня. Используется для идентификации сетевых устройств | 192.0.2.10 |
| SOCKETV4 | IPv4 адрес : Порт | Комбинация IPv4-адреса и номера транспортного порта (TCP/UDP) | 192.0.2.10:443 |
| IPV6 | IPv6 адрес | 128-битный IP-адрес сетевого уровня в шестнадцатеричной нотации | 2001:db8::1 |
| SOCKETV6 | [IPv6 адрес] : Порт | Комбинация IPv6-адреса и порта транспортного уровня. Адрес заключается в квадратные скобки для отделения от порта | [2001:db8::1]:8080 |
| URL | Унифицированный указатель ресурса | Полная строка запроса к ресурсу, включающая протокол, доменное имя (или IP), путь к файлу и параметры запроса | https://example.com/path/malware.exe |
| DOMAIN | Доменное имя (FQDN) | Символьное имя, идентифицирующее ресурс в Интернете | example.com |
| MD5 | MD5 | Хэш-сумма файла, вычисленная по алгоритму MD5 | d41d8cd98f00b204e9800998ecf8427e |
| SHA1 | SHA1 | Хэш-сумма файла, вычисленная по алгоритму SHA1 | da39a3ee5e6b4b0d3255bfef95601890afd80709 |
| SHA256 | SHA256 | Хэш-сумма файла, вычисленная по алгоритму SHA256 | e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 |
| FILE | Хэш-сумма файла | Информация о файле, идентифицируемом по его хэш-сумме по алгоритму SHA256. Метаданные объекта могут содержать дополнительные хэши (MD5, SHA1) | e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 |
Основные эндпоинты
Управление фидами:- GET /api/v2/feeds/tree - используется для получения дерева доступных для клиента фидов.
- GET /api/v2/feeds/{feed-name-by-tree} - используется для получения индикаторов конкретного фида.
Управление файлами и правилами:При вызове метода API GET /api/v2/feeds без параметров вернутся все индикаторы из доступных пользователю фидов.
Правила разделены по типам, в рамках одного типа может быть несколько коллекций.
-
GET /api/v2/rules/types - получение типов правил.
-
GET /api/v2/rules/{type}/collections - получение имен коллекций определенного типа.
-
GET /api/v2/rules/{type}/{collection}/history - получение списка файлов с правилами определенного типа и коллекции.
-
GET /api/v2/rules/{type}/{collection}/{hash} - получение файла по конкретному хешу.
-
GET /api/v2/rules/{type}/{collection}/latest - получение последней версии файла в коллекции.
-
GET /api/v2/domains/categorized/hashed - используется для получения доменов с хешированным FQDN.
-
GET /api/v2/domains/categorized/plain - используется для получения доменов с открытым FQDN.
Метод авторизации: Авторизация проводится путем передачи JWT-токена в заголовке запроса.
Примеры использования API v2
Ниже представлены практические сценарии работы с API v2, основанные на часто задаваемых вопросах клиентов.
Первоначальная выгрузка всех индикаторов фида
Для получения всех индикаторов из определенного фида необходимо выполнить выгрузку данных последовательными запросами к API. В Solar TI Feeds API для этого используется алгоритм итерации по времени обновления индикаторов updated_at, который позволяет получать данные порциями без потерь, даже если они изменились в процессе загрузки.
Шаг 1: Первый запрос без updated_at
Первый запрос выполняется без параметра updated_at.
curl --location --request GET 'https://api.data.rt-solar.ru/api/v2/feeds/4rays_pulse?direction_sort=ASC&limit=100' \
--header 'Authorization: Bearer {JWT_TOKEN}'
В ответе получается массив из 100 индикаторов, отсортированных по полю updated_at в порядке возрастания (ASC).
Предположим, последний индикатор в ответе имеет updated_at = "2025-12-10T12:42:05.321519Z".
Шаг 2: Следующий запрос с параметром updated_at
Следующий запрос выполняется с параметром updated_at, равным запомненному значению, чтобы получить индикаторы, которые изменились после указанного времени.
curl --location --request GET 'https://api.data.rt-solar.ru/api/v2/feeds/4rays_pulse?direction_sort=ASC&limit=100&updated_at=2025-12-10T12:42:05.321519Z' \
--header 'Authorization: Bearer {JWT_TOKEN}'
API вернёт только те индикаторы, которые были обновлены после указанного времени.
Шаг 3: Повторение запросов до полной выгрузки
Следующие запросы выполняются с параметром updated_at, равным значению updated_at последнего индикатора из ответа на предыдущем шаге.
curl --location --request GET 'https://api.data.rt-solar.ru/api/v2/feeds/4rays_pulse?direction_sort=ASC&limit=100&updated_at=2025-12-10T15:17:05.321519Z' \
--header 'Authorization: Bearer {JWT_TOKEN}'
Процесс итерации завершается, когда API возвращает пустой массив в ответе. Это означает, что индикаторов с updated_at позже указанного времени не существует — все данные фида успешно получены.
Получение изменённых индикаторов с момента последнего запроса
Итерирование по времени изменения индикаторов также дает возможность эффективно запрашивать только те данные, которые появились или обновились после предыдущей выгрузки. Для этого используйте параметр updated_at с алгоритмом последовательной итерации.
Шаг 1: Первый запрос
Предположим последнее известное время обновления: 2025-12-11T10:00:00.000Z, тогда запрос будет выглядеть так:
curl --location --request GET 'https://api.data.rt-solar.ru/api/v2/feeds/4rays_pulse?direction_sort=ASC&limit=100&updated_at=2025-12-11T10:00:00.000Z' \
--header 'Authorization: Bearer {JWT_TOKEN}'
В ответе API вернёт массив индикаторов, у которых поле updated_at имеет значение позже указанного времени (2025-12-11T10:00:00.000Z).
Шаг 2: Следующий запрос с параметром updated_at
Следующие запросы выполняются с параметром updated_at, равным значению updated_at последнего индикатора из ответа на предыдущем шаге.
curl --location --request GET 'https://api.data.rt-solar.ru/api/v2/feeds/4rays_pulse?direction_sort=ASC&limit=100&updated_at=2025-12-12T15:17:05.321519Z' \
--header 'Authorization: Bearer {JWT_TOKEN}'
Процесс итерации завершается, когда API возвращает пустой массив в ответе. Это означает, что индикаторов с updated_at позже указанного времени не существует — все данные фида успешно получены.
Получение новых индикаторов
Если вам нужно получить определённое количество самых свежих индикаторов (например, 500 последних изменённых записей), используйте параметр direction_sort=DESC.
Шаг 1: Запрос самых свежих индикаторов
curl --location --request GET 'https://api.data.rt-solar.ru/api/v2/feeds/4rays_pulse?direction_sort=DESC&limit=500' \
--header 'Authorization: Bearer {JWT_TOKEN}'
В ответе вы получите 500 индикаторов, отсортированных по полю updated_at от самых новых к самым старым.
Шаг 2: Получение следующей порции свежих данных
Для получения следующей порции данных (индикаторов, которые старше последнего полученного) используйте updated_at самого старого индикатора из предыдущего ответа. Например, если в предыдущем ответе последний индикатор имеет updated_at = "2025-12-10T14:20:00.000000Z":
curl --location --request GET 'https://api.data.rt-solar.ru/api/v2/feeds/4rays_pulse?direction_sort=DESC&limit=500&updated_at=2025-12-10T14:20:00.000000Z' \
--header 'Authorization: Bearer {JWT_TOKEN}'
В ответе вы получите следующие 500 индикаторов, отсортированных от самых новых к самым старым (по полю updated_at).
Важно:
- При
direction_sort=DESCпараметрupdated_atработает как верхняя граница — возвращаются индикаторы, у которыхupdated_atраньше или равно указанному значению. - При
direction_sort=ASCпараметрupdated_atработает как нижняя граница — возвращаются индикаторы, у которыхupdated_atпозже указанного значения.
Рекомендация:
- Для первоначальной загрузки и синхронизации данных используйте
direction_sort=ASCс алгоритмом итерации поupdated_at. - Для регулярного мониторинга новых угроз используйте
direction_sort=DESCс небольшим лимитом (100-200) и частыми интервалами обновления.
Механизмы устаревания IoCs
Solar TI Feeds предоставляет два механизма управления устареванием индикаторов.
- Временная метка
valid_until. - Обработка действия DELETE.
Использование временной метки valid_until
В ответе API для сетевых индикаторов (IP-адреса, домены, URL) присутствует поле valid_until. Эта временная метка указывает, до какого момента индикатор считается актуальным и должен оставаться в мониторинге. Значение valid_until автоматически рассчитывается на основе TTL (Time To Live), заданного для каждого фида.
Важно: Для файловых индикаторов (хэши MD5, SHA1, SHA256) поле valid_until отсутствует — их жизненный цикл управляется исключительно через событийную модель с действиями (CREATE, UPDATE, DELETE).
Шаг 1. Извлечение метки валидности
При получении индикатора извлеките значение поля valid_until из интересующего фида объекта feeds.
Пример ответа с valid_until фида 4RAYS_PULSE:
{
"feeds": [
{
"name": "4rays_pulse",
"action": "UPDATE",
"valid_until": "2035-12-10T12:42:05.321519Z"
}
]
}
Шаг 2. Планирование автоматического удаления
Настройте вашу систему на автоматическое удаление индикатора из интересующего фида локальной базы по истечении времени, указанного в valid_until.
Шаг 3. Обработка исключений
Учтите, что для файловых индикаторов (хэшей) метка valid_until отсутствует — их жизненный цикл управляется через событийную модель.
Обработка действия DELETE
Шаг 1. Обнаружение действия DELETE
При обработке полученных индикаторов проверяйте значение поля action в каждом объекте feeds.
Пример фида с action = "DELETE":
{
"feeds": [
{
"name": "4rays_pulse",
"action": "DELETE",
"valid_until": "2025-12-10T12:42:05.321519Z"
}
]
}
Шаг 2. Выполнение очистки
При обнаружении действия DELETE выполните следующие операции:
- Удалите индикатор из локальной базы данных.
- Прекратите его мониторинг в системах безопасности.
- Обновите правила фильтрации и блокировки.
Шаг 3. Понимание причин удаления
Действие DELETE может быть отправлено в трёх случаях:
- Истечение времени жизни индикатора (для сетевых индикаторов).
- Ручной отзыв индикатора аналитиками Solar.
- Изменение данных, при котором индикатор перестаёт соответствовать критериям фида (например, попадание фида в Белый список (whitelist)).
Рейтинг вредоносности IoCs
В Solar TI Feeds для оценки критичности индикаторов используется поле zone. Это поле следует использовать как базовый показатель вредоносности в TIP-системах.
Пример использования поля zone для определения рейтинга вредоносности:
Шаг 1. Выполнение запроса к фиду
Выполните запрос к фиду, например 4rays_pulse, чтобы получить индикаторы с оценкой критичности.
curl --location --request GET 'https://api.data.rt-solar.ru/api/v2/feeds/4rays_pulse?limit=100' \
--header 'Authorization: Bearer {JWT_TOKEN}'
Шаг 2. Получение индикаторов с полем zone
В ответе каждый индикатор будет содержать поле zone со значениями: MALICIOUS, SUSPICIOUS, UNKNOWN или CLEAN.
Пример индикатора с полем zone:
{
"id": "421da453-5f3b-4542-b8fe-099f7d9cbe2b",
"type": "IPV4",
"value": "192.0.2.100",
"zone": "MALICIOUS",
"categories": ["malware", "c2"],
"feeds": [
{
"name": "4rays_pulse",
"action": "UPDATE"
}
]
}
Шаг 3. Анализ значения поля zone
Используйте следующую таблицу для анализа значения zone:
| Zone | Описание |
|---|---|
| MALICIOUS | Индикатор представляет собой подтверждённую угрозу, связанную с вредоносной активностью. Рекомендуется немедленное блокирование и детальное расследование инцидента |
| SUSPICIOUS | Индикатор вызывает подозрения, но не имеет явных признаков вредоносной активности. Требует дополнительного анализа для подтверждения или опровержения угрозы |
| CLEAN | Индикатор полностью безопасен и не требует дополнительных мер защиты. Может использоваться для подтверждения легитимной активности |
| UNKNOWN | Информации о происхождении индикатора недостаточно, чтобы отнести его к какой-либо зоне |
Рекомендованные интервалы обновления фидов
Для эффективного использования Solar TI Feeds API и поддержания актуальности данных рекомендуется настраивать интервалы обновления в зависимости от типа фида и критичности угроз. API поддерживает высокочастотное обновление данных, при этом фактический интервал синхронизации может быть адаптирован под возможности инфраструктуры клиента:
- Рекомендуемый интервал: 15 минут для сбалансированной работы с большинством фидов.
- Для полной выгрузки фидов: 30 минут и более (в зависимости от объема данных и пропускной способности канала).
- Для инкрементальных обновлений: от 5 минут при необходимости мониторинга угроз в режиме, близком к реальному времени.
| Категория фида | Примеры | Рекомендуемый интервал | Обоснование |
|---|---|---|---|
| Критические фиды | Active_C2, APT, C2 | 15–30 минут | Требуют быстрого реагирования на новые угрозы и атаки в реальном времени |
| Фиды киберпреступности | Malware, Phishing, Ransomware, Stealer, Botnet | 2-4 часа | Баланс между актуальностью данных и нагрузкой на инфраструктуру |
| Публичные источники | GENERIC (публичные фиды) | 4-8 часов | Меньшая частота изменений по сравнению с оригинальными исследованиями |
| Официальные источники | FINCERT, FSTEC | 24 часа | Официальные бюллетени и обновления выпускаются реже |
| Сервисы анонимизации | VPN, TOR, Proxy | 24 часа | Списки сервисов анонимизации меняются относительно медленно |
Получение более 1000 индикаторов
По умолчанию параметр limit ограничен 1000 индикаторами на запрос. Чтобы получить больше индикаторов, необходимо выполнить несколько запросов с использованием пагинации по времени.
Пример для выгрузки 3000 самых новых индикаторов:
Шаг 1. Запрос первых 1000 индикаторов
Установить direction_sort=DESC для получения индикаторов, отсортированных от самых новых к самым старым.
curl --location --request GET 'https://api.data.rt-solar.ru/api/v2/feeds/generic?direction_sort=DESC&limit=1000' \
--header 'Authorization: Bearer {JWT_TOKEN}'
В результате вы получите первые 1000 записей — самые свежие индикаторы из фида.
Шаг 2. Запрос следующих 1000 индикаторов
Из ответа на предыдущем шаге определите updated_at последнего (самого старого) индикатора. Например: "2025-11-15T08:20:00.000000Z".
curl --location --request GET 'https://api.data.rt-solar.ru/api/v2/feeds/generic?direction_sort=DESC&limit=1000&updated_at=2025-11-15T08:20:00.000000Z' \
--header 'Authorization: Bearer {JWT_TOKEN}'
В результате вы получите следующие 1000 записей.
Шаг 3. Запрос третьей тысячи индикаторов
Из ответа на Шаг 2 снова определите updated_at последнего индикатора. Например: "2025-10-30T12:45:00.000000Z".
curl --location --request GET 'https://api.data.rt-solar.ru/api/v2/feeds/generic?direction_sort=DESC&limit=1000&updated_at=2025-10-30T12:45:00.000000Z' \
--header 'Authorization: Bearer {JWT_TOKEN}'
Критерий завершения:
- Получено 3000 индикаторов — целевое количество достигнуто.
- Вернётся пустой массив — в фиде больше нет индикаторов.
Если у вас остались вопросы или нужны дополнительные примеры — обратитесь в поддержку: support.tic@rt-solar.ru.